1. Field of the Invention
The invention relates to a communications technique which permits incoming multi-link point-to-point (PPP) packets of a common PPP frame to be simultaneously transmitted across more than one outgoing link, e.g., a physical channel, in a multi-link bundle. This technique is particularly, though not exclusively, suited for supporting transmission of such incoming packets over several outgoing B-channels across multiple ISDN connections.
2. Description of the Prior Art
To facilitate carriage of datagrams of different network layer protocols, such as IP (Internet Protocol), IPX, DECnet, AppleTalk and others, over a single point-to-point link, a protocol, collectively referred to as the "PPP" protocol, has recently been developed. The PPP protocol has self-contained mechanisms for specifying a specific network layer protocol to be carried in a PPP packet, testing the link itself and negotiating a variety of options for facilitating efficient communication over that link.
In particular, the PPP protocol is itself formed of three basic constituents: (a) a method of encapsulating multi-protocol datagrams--though any one packet is limited to containing a datagram that uses just one network layer protocol; (b) a link control protocol (LCP) that is capable of establishing, configuring and testing a link which is to carry PPP packet traffic between two PPP peers; and (c) a family of network control protocols (NCPs) which collectively configure the link for the various network layer protocols (such as IP, IPX and others) to be used with datagrams to be carried over that link.
In operation, the LCP, executing at two PPP peers, each on an opposite side of the link, automatically negotiates and agrees on various operational characteristics to maximize the efficiency of the ensuing communication. These characteristics include, e.g., PPP encapsulation format, size of the packets to be used, detection of looped-back links, authentication and others. To accommodate datagrams with differing network layer protocols, each datagram is encapsulated, as payload information, in a corresponding PPP packet (as a PPP "frame") and is preceded, within that PPP packet, by a protocol field that specifies the particular network layer protocol associated with that particular datagram.
Before any data is transmitted over a PPP link, each PPP peer connected to one end of the link will send LCP configuration packets to the other end to establish and test the link; thus, ensuring the link is fully operational. Once the LCP protocol has successfully completed its negotiations, the PPP peers then negotiate the necessary NCPs to properly configure the link for the different network layer protocols that are to be used; with a different NCP being negotiated for each different network layer protocol. Once the NCP(s), for the various network layer protocols, have been successfully negotiated and configured at both PPP peers, then PPP packet traffic containing encapsulated data, using the network layer protocols, can commence over that link.
During the past five years, Internet usage, particularly that of the world wide web, has exploded and continues to do so. Substantial increases still occur, on a monthly basis, not only in the size of the user community but also in the number of operational web sites. Moreover, as potential and existing site proprietors realize the potential of the Internet to very inexpensively reach an ever-increasing and diverse pool of widely dispersed potential users, these proprietors continue to post vastly increasing amounts of data, specifically, e.g., files for increasingly sophisticated web pages that include both textual and graphical information, to their web sites for user selection and downloading. Each time a user stationed at, e.g., a personal computer (PC) and using a web browser, "clicks" on a hypertext link or otherwise selects a web page, a file containing, e.g., HTML (hypertext mark-up language) source code for that page is transmitted by a remote web server through an Internet connection to the personal computer for rendering thereat. In addition, the Internet is also increasingly being used as a cost-effective method to deliver software to end users; an item of software being transmitted, again as a file(s), though oftentimes in compressed form, from a remote "ftp" (file transfer protocol) server to a personal computer then being operated by that user. Moreover, currently, the Internet also sees exploding use for disseminating files containing information in other electronic forms, such as digitized full motion video, digitized still pictures, digitized audio files and others--again selectable and accessible for downloading by a user through, e.g. associated web pages.
While the growth in available information accessible over the Internet provides an ever-increasing user community with an overwhelmingly rich information source, and one that continues to expand at a staggering rate, this growth has engendered various problems which have adversely affected the user community.
First, not only are the downloadable files, whether containing source code for web pages, software or other information, increasing in astonishing numbers but these files are also becoming much larger in size. Compressed software files on the order of tens of megabytes are becoming rather common. Inasmuch as most users connect to the Internet through dial-up telephone connections which have a rather limited bandwidth, a significant amount of time ("download" time or latency) may be required for a user to completely download a file of interest, particularly if that file is rather large, such as on the order of several megabytes or more. Second, as more users simultaneously contend for available network bandwidth at particular times, such as when the network experiences its peak daily loading, the network becomes increasingly congested. Hence, at these times, network traffic tends to slow which also tends to lengthen download time, thereby frustrating the users particularly those seeking relatively large files.
A basic approach to remedying these problems lies in cost-effectively increasing the transmission bandwidth available to a user such that a file will require much less time to download, thereby easing user frustration particularly during periods of peak network congestion.
This approach is traditionally effectuated through providing a user with the ability to cost-effectively utilize a faster transmission channel, such as, e.g., an JSDN (Integrated Services Digital Network) line, than a conventional dial-up "plain old telephone service" (POTS) analog line or an increasingly faster modem for use with a POTs line. While both of these solutions have certainly alleviated the problem, as it presently exists, to a significant extent; the problem will undoubtedly return as file sizes continue to increase, and the user community and web sites both continue to explosively expand.
Another approach is often employed, in conjunction with using high speed transmission channels, to provide further increases in transmission bandwidth to a network user. In particular, the PPP protocol, through its LCP, fortunately provides a mechanism through a so-called "multi-link protocol" (frequently referred to as simply multi-link PPP), that can assign additional bandwidth, on demand, (so-called "BonDing") in those situations where two PPP peers can be connected through multiple physical links in a common bundle (the entire multi-linked connection is commonly referred to as a "pipe"). In essence, multi-link operation involves real-time allocation (and deallocation) of any number of these links in the bundle to a common communication channel, i.e., the pipe, in order to dynamically provide sufficient transmission bandwidth for the underlying communication that is then to be carried by the channel.
For example, consider multi-link PPP being used over a basic rate interface (BRI) ISDN connection. Once successfully negotiated between two PPP peers, then, at a transmitting peer, multi-link PPP segments a packetized data stream (i.e., a PPP frame) into segments (or fragments), forms a stream of multi-link PPP packets each containing one such a segment, and then assigns these multi-link PPP packets on an approximately equal basis, where practical, between two B channels in the BRI connection for transmission to a receiving PPP peer; here the two B channels form a pipe. Small packets may not be segmented and to accommodate links of different speeds (which is not the case with two ISDN B channels), the segments need not be of the same size nor do the same number of segments need to be transmitted over each link. In any event, each such multi-link PPP packet contains a sequence number--which increases by one with each successive packet, inserted by the multi-link protocol. At the receiving peer, the multi-link protocol extracts the segments from the received packets carried by the pipe, and re-assembles these segments into proper order based on their corresponding sequence numbers so as to properly and fully reconstruct the PPP frame.
One can readily appreciate that, by simultaneously utilizing available transmission bandwidth provided by multiple links to carry packet traffic that forms a PPP frame for a given user, multi-link PPP can significantly increase overall transmission bandwidth for that user.
However, the multi-link protocol, as it presently exists, suffers from a drawback that effectively prevents this protocol from providing even further increases in transmission bandwidth, particularly where, e.g., ISDN lines are used to carry packet traffic between two PPP peers.
In particular, to exploit the increased bandwidth available from simultaneous use of multiple links, a number of currently available and forthcoming client personal computer (PC) operating systems can segment a single PPP frame into multi-link PPP packets, i.e., for subsequent carriage across a pipe formed of separate corresponding physical links.
In this regard, multi-link PPP packets can be transported over, e.g., a pipe formed of a plurality of POTs lines, each with a separate modem and a corresponding serial communication port on a client PC. This approach operates quite well with communication devices, such as modems, that have one incoming data path and one outgoing data path and do not implement the PPP protocol. However, this approach does not function, owing to, what the art believes, is a limitation inherent in multi-link PPP frame re-assembly, with communication devices, such as ISDN terminal adapters, that possess one incoming data path and several outgoing data paths and implement the multi-link protocol.
To appreciate this limitation, consider a situation where a client PC were to generate multi-link PPP packets for a common PPP frame and distribute these packets among two or more separate links with a separate ISDN terminal adapter connected to each link. As noted above, each multi-link PPP packet would contain a sequence number, in this case assigned by the PC and which increments by one from each multi-link PPP packet for a common PPP frame to the next. To ensure proper ordering, each terminal adapter, were it to use the multi-link protocol, would buffer each incoming multi-link PPP packet it receives and then reorder its received packets based on their sequence numbers, and then transmit only properly reordered packets amongst its two ISDN B channels. If incoming multi-link PPP packets were received, but with gaps in their sequence numbers, a conventional terminal adapter, then executing the multi-link protocol, would simply buffer these incoming packets pending receipt of those packets containing the missing sequence numbers. However, these "missing" packets would never arrive at that particular terminal adapter. Specifically, since the client PC is intentionally distributing packets, generally on a round-robin basis, among several links to the terminal adapters, then each terminal adapter would not receive a stream of incoming multi-link PPP packets with sequence numbers that would consecutively increase by one, but rather would increase by the number of links across which the personal computer is distributing the multi-link PPP packets. The existence of incoming multi-link PPP packets, at each terminal adapter, with gaps in their sequence numbers would totally frustrate transmission of these packets through the terminal adapters and preclude their downstream communication to a PPP peer. Thus, the incoming PPP frame applied across all the terminal adapters would never "get through" the adapters.
As such, multi-link PPP packets can only be handled by communication devices that have one incoming data link and one outgoing data link. Such a device, typified by a conventional analog modem, simply transmits incoming data appearing on its incoming data link onto its outgoing data link once a communication path is established therebetween. These devices simply do not utilize the multi-link protocol and, as such, ignore the multi-link segmented nature of the incoming data. However, conventional high-speed communication devices, such as ISDN terminal adapters, that process a stream of incoming packetized data, such as through segmentation and sequencing, to utilize multiple outgoing data links can not function with, as discussed above, incoming multi-link PPP packets. Consequently, though a client PC can generate multi-link PPP packets, high speed communication devices that execute the multi-link protocol can not handle these packets as input; thus relegating a user to much slower speed communication devices, such as analog modems, that can.
Thus, in practice, the promise of providing significantly higher user transmission bandwidth, through use of client PC software that executes the multi-link protocol, has yet to be fully satisfied.
Therefore, a need exists in the art for a technique, specifically apparatus and accompanying methods, for use in a communication device with one incoming physical link and multiple outgoing physical links for properly handling incoming multi-link PPP packets. Such a technique would permit incoming multi-link PPP packets, appearing on any one of several incoming physical links, to themselves be transmitted over a pipe formed of several outgoing physical links, thereby providing significantly increased transmission bandwidth to a user. Advantageously, this technique would find particular, though not exclusive, application in, e.g., an ISDN terminal adapter which were to receive multi-link PPP packets from a client PC, thus allowing that client to simultaneously utilize more than one ISDN terminal adapter, and correspondingly more than 2 B channels on a pipe, to attain such increased bandwidth.